ソフトウェアアーキテクチャの基礎輪読会 7章
日付：11/10
章：7章 アーキテクチャ特性のスコープ
調査者：kiri.icon
章のまとめ
どんな内容が書かれているか？
要約
高度な機能的凝集性と同期的なコナーセンスを持つ、独立してデプロイ可能なアーティファクト。
コンポーネントがどのように「つながっている」かを計測する指標
takasshii.icon要約いいね
アーキテクチャ量子が定義されるまでの経緯
経緯
-> 従来のコードベースのメトリクスではなく、データベースなどの外部依存コンポーネントも考慮したメトリクスがほしい。
-> 「アーキテクチャ量子」という概念を提案
アーキテクトは運用特性を評価する際、外部依存コンポーネントも考慮する必要がある。
https://scrapbox.io/files/654d7164387334001cce77a9.png
コードの細かな結合メトリクスは、アーキテクチャレベルの分析だと具体的すぎる。
システム内のコンポーネント間の相互依存性を示すもの。
アーキテクチャ量子を定義するには、コンポーネント間の「つながり」を理解し計測することが重要 静的コード解析によって発見可能
takasshii.iconそういう意味だったのか👀
ex.) 2つのマイクロサービスがUserというクラス定義を共有している場合、クラス定義を変更する際には、両方のサービスのコードを変更する必要がある。
同期的なもの
呼び出し元は呼び出し先からの応答を待つ
非同期的なもの
応答を待たない
物理学的な量子
相互作用に関与するあらゆる物理的実体の最小量
高度な機能的凝集性と同期的なコナーセンスを持つ、独立してデプロイ可能なアーティファクト。
独立してデプロイ可能
アーキテクチャ量子は、アーキテクチャの独立した機能単位で、システムの他の部分から独立してデプロイ可能である必要があるすべてのコンポーネントを含む。 takasshii.iconマルチモジュールのモジュールはアーキテクチャ量子じゃないのね（個別デプロイできないので）
高度な機能的凝集性
機能的凝集性はコンポーネントがどれだけ目的に沿って統一されているかを示す。
各サービスが特定のワークフローや境界づけられたコンテキストに沿って設計されるため、高い機能的凝集を達成することが一般的
ex.) LINEギフトがギフトを送ることのみに特化している
分散サービス間での同期的な呼び出しを指し、マイクロサービスアーキテクチャに置いては、サービスが互いに直接呼び出し合うことを意味する。
呼び出し元と呼び出し先の運用特性が異なる場合、タイムアウトなどの信頼性の問題が発生してしまうため、同期的なコナーセンスでは、サービス間の運用特性が一致している必要がある。
kiri.iconコナーセンスむずい
takasshii.iconここって下の例の意味よね、、？
takasshii.icon同期にすると、アーキテクチャ特性が違う場合にタイムアウトとかしちゃうので、相互呼び出しの同期非同期の判定は慎重にしましょうってことかな？
kiri.iconそういうことか！
ex.)
PaymentサービスとAuctionサービスを含むマイクロサービスアーキテクチャ
Auctionサービス
オークション終了時に決済情報を送信する
Paymentサービス
限られた頻度でしか処理を行えない
同期通信ではタイムアウトが発生する可能性があるため、アーキテクトは非同期通信を採用する必要がある。
この非同期的なコナーセンスにより、システムはタイムアウトの問題を回避できる。
takasshii.iconなるほど、非同期が必要な例わかんなかったからいいね
ドメイン駆動設計(DDD)
境界づけられたコンテキストを使用して、ドメインの明確な範囲を定義する。
これにより、過去に組織全体で共有されていた共通エンティティに関連する結合や複雑さの問題を解消し、各問題領域において独自のエンティティを定義する。
例えば、「Customer」というクラスが各コンテキスト内で異なる形で定義され、コンテキスト間のインターフェースで調整される。
takasshii.iconDDDってData Class (ドメインオブジェクト)に制限入れましょうって感じかとおもてた
takasshii.icon:naruhodo...
kiri.icon調べて追記します！
ネットオークション会社のカタ
あるオークション会社は、オンラインオークションを全国規模で展開したいと考えている。顧客は参加するオークションを選び、オークションが始まるまで待ってから、あたかもその場にいるかのように競売人と共に入札を行う。
ユーザー数
- オークションごとに数百人の参加者から、場合によっては数千人の参加者を想定している。可能な限り多くのオークションを同時に行える。
要件
- オークションは可能な限りリアルタイムで行う必要がある。
- 入札者はクレジットカードを登録し、落札した場合は、システムが自動的にカードで決済を行う。
- 参加者は、オークションでの評価指標によって追跡されなければならない。
- 入札者は、オークションの様子やすべての入札のライブビデオストリームを見ることが可能。
- オンラインとライブの両方で、入札された順番で入札を受け取らなくてはならない。
追加コンテキスト
- オークション会社は、小規模な競合他社と合併することで積極的に拡大している。
- 予算の制約はない。これは戦略的な方向性だ。
- 会社は、詐欺を主張する訴訟を解決したばかりだ。
1. 「全国規模」「オークションごとに数百人の参加者から、場合によっては数千人の参加者を想定している。可能な限り多くのオークションを同時に行える」「オークションは可能な限りリアルタイムで行う必要がある。
スケーラビリティ
弾力性
オークション終了時に入札が集中するというドメイン知識からくる暗黙的な特性
2.「 入札者はクレジットカードを登録し、落札された場合は、システムが自動的にカードで決済を行う」「会社は、詐欺を主張する訴訟を解決したばかりだ」
セキュリティ
事実上すべてのアプリケーションに暗黙的に備わっているアーキテクチャ特性
3. 参加者は、オークションでの評価指標によって追跡されなければならない
反荒らし性
「評価指標によって追跡」
監査可能性やログ収集可能性を示唆している、、？
これらがアーキテクチャ特性であるかどうかは、アーキテクチャ特性の定義へと立ち返って考えてみたり、ビジネスアナリストなどに依頼して、「評価指標」のフレーズの考え方を説明してもらう。
takasshii.iconビジネス側と話すの大事よね（前の章でも出てきた）
takasshii.iconただ、ビジネス側は利益を最大化しようとするのでエンジニアとしてもちゃんと正当性を主張しないとね（今仕事でそうなってる）
ichimura.icon👀
4. オークション会社は、小規模な競合他社と合併することで積極的に拡大している
アーキテクチャの要件は、アプリケーションの設計には直接影響しないが、選択肢を比較する際の重要な決定要因となることがある。
アーキテクトが通信プロトコルを含む技術的詳細を選ぶ際には、特定の事情に最適な選択を自由に行える場合もあれば、相互運用性のようなトレードオフを考慮して妥協をする必要が出てくる。 5. 予算の制約はない。これは戦略的な方向性だ
いくつかのアーキテクチャ・カタでは、現実世界によくあるトレードオフを表すために、予算制限を課すものがあるが、今回のアーキテクチャ・カタではその制約がない。
アーキテクチャに集中するための文
6. 入札者は、オークションの様子やすべての入札のライブビデオストリームを見ることが可能」「オンラインとライブの両方で、入札された順番で入札を受け取らなくてはならない
takasshii.iconこれめっちゃむずそう
この要件が示すアーキテクチャ上の課題は、アプリケーションの構造に確実に影響を与え、アーキテクチャ特性のスコープをシステム全体とすることの無意味さを表している。
「競売人1人と何百人もの入札者のうちの1人に対する可用性や信頼性は同じだけ重要だろうか？」
No
競売人がサイトにアクセスでなければ、誰一人オンライン入札できないという点で、競売人の可用性のほうが重要
takasshii.icon競売人って運営側ってことかな、？
kiri.icon出品する人のことだと思う
この要件は、システムレベルよりも細かいアーキテクチャのスコープが必要であることを示している。
このカタでは、「入札のストリーミング」「オンライン入札者」「競売人」の3つは異なる特性を必要としている。
takasshii.iconうわ〜めちゃめちゃ複雑になりそうなのでサーバー側に押し込めてえ））
アーキテクトはアーキテクチャに異なるアーキテクチャ特性を分析することで、プロセスの早い段階でハイブリッドなアーキテクチャ設計に取り組める。
入札者の反応
入札ストリームと入札の動画ストリームを包含している
- 可用性
- スケーラビリティ
- パフォーマンス
競売人
ライブの競売人
- 可用性
- 信頼性
- スケーラビリティ
- 弾力性
- パフォーマンス
- セキュリティ
入札者
オンラインの入札者と入札
- 信頼性
- 可用性
- スケーラビリティ
- 弾力性
takasshii.iconお疲れ様でした！！！
ichimura.iconおつかれさまでした！！カタっていうので細かい整理ができるので、細かく詰めるのが重要って感じました。
iNoma.iconめっちゃ資料わかりやすかったです！！！
質疑応答